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Abstract. We present an algebraic treatment of exception handlers and, 
more generally, introduce handlers for other computational effects repre¬ 
sentable by an algebraic theory. These include nondeterminism, interac¬ 
tive input/output, concurrency, state, time, and their combinations; in 
all cases the computation monad is the free-model monad of the theory. 
Each such handler corresponds to a model of the theory for the effects 
at hand. The handling construct, which applies a handler to a compu¬ 
tation, is based on the one introduced by Benton and Kennedy, and is 
interpreted using the homomorphism induced by the universal property 
of the free model. This general construct can be used to describe previ¬ 
ously unrelated concepts from both theory and practice. 


1 Introduction 

In seminal work, Moggi proposed a uniform representation of computational ef¬ 
fects by monads [1-3]. The computations that return values from a set X are 
represented by elements of TX, for a suitable monad T. Examples include excep¬ 
tions, nondeterminism, interactive input/output, concurrency, state, time, con¬ 
tinuations, and combinations thereof. Plotkin and Power later proposed to focus 
on algebraic effects, that is effects that allow a representation by operations and 
equations [4-6]; the operations give rise to the effects at hand. All of the effects 
mentioned above are algebraic, with the notable exception of continuations [7], 
which have to be treated differently (see [8] for initial ideas). 

In the algebraic approach the arguments of an operation represent possible 
computations after an occurrence of an effect. For example, using a binary choice 
operation or:2 , a nondeterministically chosen boolean is represented by the term 
or(return true, return false): Fbool, where Fa stands for the type of computations 
that return values of type a. The equations of the theory, for example the ones 
stating that or is a semi-lattice operation, generate the free-model functor, which 
is exactly the monad proposed by Moggi to model the corresponding effect [9] 
(modulo the forgetful functor) and which is used to interpret the type Fa. The 
operations are then interpreted by the model structure. When viewed as a fam¬ 
ily of functions parametric in X, e.g., orx: TX 2 —> TX, one obtains a so-called 
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algebraic operation ; such families are characterised by a certain naturality con¬ 
dition [5]. 

Although this gives a way of constructing, combining [10], and reasoning [11] 
about algebraic effects, it does not account for their handling, as exception han¬ 
dlers, a well-known programming concept, fail to be algebraic operations [5]. 
Conceptually, algebraic operations and effect handlers are dual: the former could 
be called effect constructors as they give rise to the effects; the latter could be 
called effect deconstructors as they depend on the effects already created. Filin- 
ski’s reflection and reification [ 12 ] are closely related general concepts. 

This paper introduces a handling construction for arbitrary algebraic effects. 
The central new idea is that, semantically, handling a computation amounts 
to composing it with a unique homomorphism guaranteed by universality. The 
domain of this homomorphism is a free model of the algebraic theory of the 
effects at hand; its range is a programmer-defined model of the algebraic theory; 
and it extends a programmer-defined map on values. The principal example 
is exception handling, particularly the exception-handling construct of Benton 
and Kennedy [13], which our new construct generalises. It also includes many 
other, previously unrelated, concepts. For example, stream redirection of shell 
processes, renaming and hiding in CCS [14], timeout, and rollback can all be 
seen as instances of such handlers. 

In Section 2 we explain the idea of using homomorphisms for the seman¬ 
tics of handlers via an informal discussion of exception handlers. In the follow¬ 
ing Sections 3, 4 and 5 we develop a formal calculus in the call-by-push-value 
framework [15,11]. Section 3, describes (base) values and the algebraic theory 
of effects. A natural need for two languages arises: one to describe handlers, 
given in Section 4, and one where they are used to handle computations, given 
in Section 5. The second parts of these sections give the relevant denotational 
semantics; readers may wish to omit these and continue with Section 6 , where 
we give examples. 

We outline a version of a logic for algebraic effects [11] with handlers in Sec¬ 
tion 7. In Section 8 we sketch the inclusion of recursion: until then we work only 
with sets and functions, but everything adapts straightforwardly to w-cpos (par¬ 
tial orders with sups of increasing sequences) and continuous functions (mono¬ 
tone functions preserving sups of increasing sequences). Finally, we discuss some 
open questions and possible future work in Section 9. 


2 Exception handlers 

We start our study with exception handlers both because they are an established 
concept [13,16] and also because exceptions provide the simplest example of 
algebraic effects. To focus on the exposition of ideas, we write this section in a 
rather informal style, mixing syntax and semantics. 

Taking a set of exceptions E, the computations that return values from a 
set X are represented by elements, 7 , of TX = de f X + E: the unit of the monad is 
i) = ih inl(x). Algebraically, one may take a nullary operation, i.e., a constant, 
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raise e : 0 for each e £ E and no equations, and then FX has a carrier TX with 
raise e interpreted as inr(e). 

An exception handler 

7 handle {e i-> x e } eeE 

takes a computation 7 £ X + E and intercepts raised exceptions e £ E, carrying 
out predefined computations x e £ E instead (if one chooses not to handle a 
particular exception e one takes x e = raise e ). So we have the two equations: 

r](x) handle {e 1—> x e } eeE = inl(x) , 
raise e handle {e i-> x e } eeE = x e . 

From an algebraic point of view, the x e provide a model for the theory of 
exceptions onI + £, interpreting each operation raise e by x e . If we write X + E 
for the free model and X'^E for the new model on the same carrier set, we see 
from the above two equations that 

h( 7) =def 7 handle {e 1—> ® e }ee£ 

is the unique homomorphism h: X + E X + E extending ini: X —> X + E 
along the unit y. 

Benton and Kennedy [13] generalised the handling construct to one 
try a; 4= 7 in g(x) unless {e y e }eeE , 

where exceptions e may be handled by computations y e of any given type M (here 
a model of the theory); returned values are “handled” with a map g: X —> M. 
(This construct is actually a bit more general than in [13] as E may be infinite 
and as we are in a call-by-push-value framework rather than a call-by-value one.) 
We now have: 


try a; <^= rj(x) in g(x) unless {e i-> y e } eeE = g(x) , 
try® <^= raise e \ng(x) unless{e y e } e eE = y e ■ 

As they remarked, this handling construct allows a more concise programming 
style, program optimisations, and a stack-free small-step operational semantics. 

Algebraically we now have a model M on (the carrier of) M, interpreting 
raise e by y e , and the handling construct corresponds to the homomorphism h 
induced by g, that is the unique homomorphism h: X + E —> M extending g 
along y. Note that all the homomorphisms from the free model are obtained in 
this way, and so (this version of) Benton and Kennedy’s handling construct is 
the most general one possible from the algebraic point of view. 

We can now see how to give handlers of other algebraic effects. To give 
a model of an algebraic theory on a set X is to give a map / op : X n —> X 
for each operation op : n, on condition that those maps satisfy the equations 
of the theory. As before, computations are interpreted in the free model and 
handling constructs are interpreted by the induced homomorphisms. Intuitively, 
while exceptions were simply replaced by handling computations, operations are 
recursively replaced by handling functions on computations. 
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3 Values and effects 


3.1 Base signature and interpretation 

We start with a base signature T\ )a , S e> consisting of: a set of base types (3; a 
subset of base types, called the arity types or, a collection of function symbols 
f: (/3) —* [3: and a collection of relation symbols R:(J3). We use vector notation 
a to abbreviate lists a\,... ,a n . 

Base terms v are built from variables and function symbols, while base for¬ 
mulas ip are built from equations between base terms, relation symbols applied 
to base terms, logical connectives, and quantifiers over base types. In a con¬ 
text r of variables bound to base types, we type base terms as E h v: [3 and 
base formulas as r h <p: form. 

An interpretation of the base signature is given by: a set [/?] for each base 
type (3, countable when (3 is an arity type; a map [/]: |/3] —> [/?] for each 
function symbol f:(/3) —» (3: and a subset [ii] C |/3] for each relation symbol R: 
(/3), where [/3] = |/3i] x ... [/?„]. Terms fh v:j3 and formulas T h y>:form are 
interpreted by maps [v]: [T] —> |/3] and subsets [<^] C [T] as usual [17]. 


3.2 Effect theory 

Standard equational logic does not give a finitary notation for describing effects 
given by an infinite family of operations, having an infinite number of outcomes, 
or described by an infinite number of equations [5]. We present a more general 
notation to do this, at least in some cases. We assume a given base signature 
and interpretation. 

To avoid infinite families of operation symbols, we allow operations to have 
parameters of base types. For example, instead of having a family of operation 
symbols update; d : 1 for each location l and datum d, we take a single operation 
symbol update: loc, dat; 1 that takes parameters l: loc and d: dat, which give 
the memory location to be updated and the datum to be stored there. 

To avoid operation symbols with infinite arity, we allow each argument of 
an operation to be dependent on the outcome of an effect, which is a value of 
an arity type. For example, the argument of an operation lookup : loc; dat is 
dependent on the datum d: dat, stored in the memory location l: loc, supplied 
to it as a parameter. 

Thus, an effect signature E e g consists of operation symbols op:/3; oq,..., a n , 
where (3 is a list of the parameter base types, and Qi,...,a n are lists of argument 
arity types. We omit the semicolon when (3 is empty, and we write n instead of 
«!,..., a n when all the a, are empty. Effect terms T, which serve as templates 
for computations, are given by the following grammar: 

T::=w(v ) | op^aq:oq.Tj)* , 

where w ranges over effect variables, and op„ ( x t : a, .7^;], is an abbreviation for 
op v (xi :a.\.T\,..., x n :ct n .T n ). 
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We type effect terms as T; A \- T, where A consists of effect variables w: (a), 
according to the following rules: 


r \- v:a 
r-A\- w(v) 


(w :(<*)£ A) 


r\~v:f3 r.Xj -.cti: A - (i= 1..... ?i) 

F; A h op^aq: aq.TjE 


(op:/3; ai,, a n £ E eS ) . 


Next, conditional equations have the form T;A h Ti = Ti (y), assuming that 
r-.Ah T,, 7’: zl h T 2 , and -T h y:: form. Finally, a conditional effect theory is 
a collection of such equations; it would be interesting to develop an equational 
logic for such theories [18]. 


Example 1. To describe a set E of exceptions, the base signature consists of a 
base type exc and a constant function symbol e : () —> exc for each e £ E. 
We interpret exc by E and functional symbols by their corresponding elements. 
The effect signature consists of an operation symbol raise : exc;0, while the 
effect theory is empty. Then, omitting empty parentheses, raise e represents the 
computation that raises the exception e. 


Example 2. For nondeterminism, we take the empty base signature, the empty 
interpretation, the effect signature with a single nondeterministic choice opera¬ 
tion symbol or: 2, and the effect theory for a semi-lattice, which states that or is 
idempotent, commutative, and associative. 


Example 3. For state, the base signature contains a base type loc of memory 
locations, an arity type dat of data, and appropriate function and relation sym¬ 
bols to represent the locations and data. We interpret loc by a finite set L and 
dat by a countable set D. The effect signature consists of operation symbols 
lookup: loc; dat and update: loc, dat; 1, while the effect theory consists of seven 
conditional equations [9,18]. As an example term, lookup ; (d: dat.update ; , d (w)) 
represents the computation that copies d from l to l' and then proceeds as w. 

Each effect theory <£ gives rise to a standard (possibly infinitary) equational 
theory [19]. For each op:/3: «i,.... a n £ E e s and b € |/3], we take an operation 
symbol op b of countable arity [a,] |. Then each term r-,A\~T and each 
c £ [-T] give rise to a term A' h T c , where A' consists of variables w a for each 
w : (a) £ A and a £ [a]. The equations of the theory are A' h T c = T c / for any 
equation T; A h T = V (y>) in € and any c e [y>]. 

A model of the effect theory is a set M together with a family of maps 
{°Pm : 1/3] x EL MM —> M} op:j g ;c , li ... iCtne j; eff , such that the corresponding 
maps op M (b, —), where b £ |/3], satisfy the equations of the induced infinitary 
effect theory. A homomorphism between models M and A’ is a map /: M —> N 
such that op N o (idpj x [Qj /^I) = / o op M holds. 

Models and homomorphisms form a category Mode, equipped with the for¬ 
getful functor U: Mode —^ Set, which maps a model to its underlying set and a 
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homomorphism to its underlying map. This functor has a left adjoint F, which 
constructs the free model FA on a set of generators A. The set UFA rep¬ 
resents the set of computations that return values in A, and the monad UF 
corresponds [9] to the monad proposed by Moggi to model the corresponding 
effect [2]. The monad induced by the theory for exceptions in Example 1 maps 
a set X to X + E, the one for non-determinism in Example 2 maps it to the set 
F + (X) of finite non-empty subsets of X, while the one for state in Example 3 
maps it to (S x X) 5 , where S = D L . One can give an equivalent treatment using 
countable Lawvere theories [20]. 


4 Handlers 


Exception handlers are usually described and used within the same language: 
for each exception, we give a replacement computation term, which can contain 
further exception handlers. Repeating the same procedure for other algebraic 
effects is difficult: in order to interpret the handling construct, the handlers have 
to be correct in the sense that the redefinition of the operations they provide 
yields a model of the effect theory. 

Instead of equipping a single calculus with a mechanism to verify that han¬ 
dlers are correct, we avoid this complex interdependence between well-formed¬ 
ness and correctness by providing two calculi. One, given in this section, enables 
the language designer to specify handlers; one, given in the next section, enables 
the programmer to use them. In this way the selection of correct handlers is 
delegated to the meta-level. 

Handlers are described by handler types \ and handler terms h, given by the 
following grammar: 

X ::= X | Fcr | 1 | xi x X2 | o-^ x , 

h ::= z(v) | op„(sCj: aj./q)* | if-then hi elsefo | return u | let x be h in h! \ 

* | (/ii,/i2) | fst/i | sndh | Xx:a.h \ hu , 


where X ranges over type variables, a ranges over value types, z ranges over 
handler variables, u ranges over value terms, and p in the conditional statement 
ranges over quantifier-free formulas. For the sake of simplicity, only the most 
basic programming constructs are present, and the only value types and terms 
are the one stemming from the base signature. 

Handler terms h are typed with handler types x in a context F of variables, 
bound to value types, and a context Z of handler variables z : (a) —* x> where 
we write z : x if a is empty, according to the following rules: 


Fft v.a 
r-,Z\- z(v): x 


fyfya) 


xez) 


r \- v:(3 r,Xi:oii-,Z\-hi-.x (* = 1. n) 

F; Z I- op„(aq: aq./if);: x 
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r\-u:a F; Z h h: Fa F,x:a-, Z h h! : X 

r,Z h return u:Fo F; Z h let x be ft in h!: \ 

and the standard rules for conditionals, products, and functions. 

For greater generality, handlers are parametric in two ways: their type con¬ 
tains type variables, and they are dependent on parameters x p and z p , supplied 
through the handling construct. A handler is given by a handling term for each 
operation, dependent on its parameters x and arguments z, and is typed by 

x p :<T,x:p-,z p -.x,{ z i-( a i) x)£=i h h o P -X (op:/3; n b ■. ■, a n g F e ff) 

h (x p :a ; z p : x).{op x (z) h op } opeEeft : (a; x) X handler 

When op x (z) i-» h op is omitted, we assume that h op = op a ,(o: on.Zi(xi))i, so 
that op is not handled. 

4.1 Semantics 

For each assignment of models [X] to type variables X, handler types \ are 
interpreted by models [x], given by 

{Faj = F[aj [1] = 1 

Ixi X X2] = [xi] x [X2I h -*• x] = lxi M , 

where the model is given component-wise on Mi x M2 and point-wise on M A . 

Then, we interpret contexts Z = z\\ (cci) —> xi,...,z n : (a„) —> Xn by 
[Z] = f/[xi]^“^ x ••• x and handler terms F;Z \- ft: x by maps 

[ft]: [-T] x [Z] —> U [x], defined inductively by 

[F; Z b Zi(v) :xj = ev o {pr^j^j ,[«]), 

\r-,Z\- op v (xi.hi)i:xl =op [x j o(M,[fti],...,[ft n ]} , 

[F; Z h return u: Faj = r] M o [u] , 

[F;Z h let x be ft in ft' : X ] = Wf o (id r ,id z , [ft]} , 

where f:B—> C A is the transpose of /: A x B —> C and p: Ax UFB —> UM 
is the lifting of /: A x B —> UM, which is defined by Ue o UFf o st^.s, where 
st a,b- A x UFB —* UF(A x B) is the strength of the functor UF. The inter¬ 
pretations of conditionals, products, and functions are defined as usual [15]. 

A handler (x p :cr; z p : x).{op x (z) h 0 p}opei;eff : ( CT ; X) ^ X handler is cor¬ 
rect (with respect to <£) if for all assignments of models [X] to type variables X, 
and for all parameters a p £ [er] and m p £ Ixl , the family of maps 

{[ftop] o(a p ,pr M ,m p ,pr ni[/M[c . <1 }: [0] x J^Flx] 1 ^ 1 -► U[ X j } op eE ell 


defines a model of the effect theory <£ on F[x]- 





5 Computations 


A handler signature Ahand consists of handler symbols H, each with a corre¬ 
sponding correct handler. Then, computation types r and computation terms t 
are given by the following grammar: 

■r ::= Fcr \1 \t x Xt 2 \ a 

t::=op v {xi\oii.ti)i | if ip then t\ else t 2 | return it | letxbefint' | 

try t with if (it; t) asx in t' \ * \ (tiftf) | fst t | snd t \ \x:a.t \ tu . 

One can see that computation types and terms mirror their handler counter¬ 
parts, with the omission of type and handler variables, and the addition of the 
handling construct. When the extended handling construct is not necessary, we 
write handle t with H(u] t) instead of try t with H(u; t) as x in return x, and when 
the handler signature consists of a single handler symbol H, we omit it and 
simply write try t with it; t as a; inf'. 

We can extend both handlers and computations with other call-by-push-value 
constructs [15]. A problem arises if we introduce thunks: handler terms then 
contain value terms, which contain thunked computation terms, which contain 
the handling construct. To resolve the issue, we would further split the handler 
types and terms into value and computation ones. 

Computation terms t are typed with computation types r, according to rules 
similar to the ones for handling terms, while the handling construct for a handler 
H:(a ; x) —> y handler £ Ahand typed by 

r\-t:Fa r \- u:cr r\-t:x[r/X] A, x: a b t' : x[r/ X] 
r \- try t with H(u\ t ) asxin t' :x[r/X\ 

where x[t/X] is the computation type obtained by replacing all the type vari¬ 
ables X in % by computation types r. A handler H : (a; x) —* X handler is 
uniform, if x = X, and parametrically uniform, if x = c —> X. 

5.1 Semantics 

Computation types and terms are interpreted in the same way as their han¬ 
dler counterparts, while the handling construct is interpreted as follows. Each 
handler H : (er; %) —> x handler £ A han d is correct and so induces a model 
[x[r/W] with H(u: f)] for any assignment of computation types r to type vari¬ 
ables X, any value terms r \- w.cr, and any computation terms T b t : x[t/ X], 
From the universality of the free model -F[c7], we get the unique map [£'], ho¬ 
momorphic in the second argument, for which the diagram below commutes. 

PI x UF\a\ 



PI x la] -M. U\x\t/X] with 



Then, T h try t with H(w, t) asx in t' is interpreted by 


[t'J o <id [r j,[t]>: [71 U\x[t/X] with H(u; £)] = U{ X [t/X]\ . 


6 Examples 

6.1 Exceptions 

The standard uniform exception handler i/ exc : (exc —> X ) —> X handler is 
(z:exc —> X).{raise e () i—> zej . 

Benton and Kennedy’s construct try a; <= tint' unless {ei => ti | • • • | e n => t n } 
can then be written as try t with t exc as x in t! for a suitable term t exc : exc — > r. 

Benton and Kennedy noted a few issues about the syntax of their construct 
when used for programming [13]. It is not obvious that t is handled whereas t' 
is not, especially when t' is large and the handler is obscured. An alternative 
they propose is try x <= t unless {ei => t\ \ ... \ e n => t n }i in t', but then it is not 
obvious that x is bound in t', but not in the handler. The syntax of our con¬ 
struct try t with H(u] t) as x in t' addresses those issues and clarifies the order of 
evaluation: after t is handled with H, its results are bound to x and used in t'. 


6.2 Stream redirection 

Shell processes in UNix-like operating systems communicate with the user us¬ 
ing input and output streams, usually connected to a keyboard and a terminal 
window. However, such streams can be rerouted to other processes and simple 
commands can be combined into more powerful ones. 

One case is the redirection proc > outf ile of the output stream of a pro¬ 
cess proc to a file outf ile, usually used to store the output for a future analysis. 
An alternative is the redirection proc > /dev/null to the null device, which ef¬ 
fectively discards the standard output stream. 

Another case is the pipe prod | proc2, where the output of prod is fed to 
the input of proc2. For example, to get a way (not necessarily the best one) of 
routinely confirming a series of actions, for example deleting a large number of 
files, we write yes | proc, where the command yes outputs an infinite stream 
made of a predetermined character (default one being y). 

We represent interactive input/output by: a base signature, consisting of 
a base type char of characters and constants a, b,... of type char, together 
with the obvious interpretation; an effect signature, consisting of operation sym¬ 
bols out : char; 1 and in : char, with the empty effect theory. Then, if t is a 
computation, we can express yes I t > /dev/null by handle t with i? re d, where 
H led :X handler is given by (out c (2:) i—► z, in(2:) i-> z( y)}. 



6.3 CCS renaming and hiding 


In functional programming, processes are regarded as programs of the empty 
type 0. The subset of CCS processes [21], given by action prefix and sum, can 
be represented by: a base signature, consisting of a base type act of actions 
and appropriate constants for actions, interpreted in the evident way; an effect 
signature, consisting of operation symbols 0:0, do : act; 1 , and + : 2, with 
the obvious effect theory [11]. Then, process renaming t[b/a] can be written as 
handle t with H len (a, b) using the handler H ren : (act, act) —> TO handler, where, 
writing a.z for do a (z): 

H len = (a: act, b: act). {o'. z if a' = a then b.z else a'.zj . 

Hiding can be implemented in a similar way, but, and most unfortunately, it 
seems that parallel cannot be, as it is recursively defined on the structure of two 
processes and thus apparently requires a binary variant of handlers. Presently, 
we do not see a possible such generalisation, as primitive recursion is inherently 
defined on a single structure. 


6.4 Explicit nondeterminism 

The evaluation of a nondeterministic computation usually takes only one of all 
the possible paths. But in logic programming [22,23], we do an exhaustive search 
for all solutions that satisfy given constraints in the order given by the solver im¬ 
plementation. Such nondeterminism is represented slightly differently from the 
one in Example 2. We take: the empty base signature; the effect signature, con¬ 
sisting of operation symbols fail: 0 and pick: 2, with the effect theory consisting 
of the following equations stating that the operations form a monoid: 

w h pick(w,fail()) = pick(fail(), w) = w , 
wi,w 2 ,w 3 \~ pick(w; 1 , pick(w 2 , W3)) = pick(pick(w 1 , u? 2 ), w 3 ) . 

The free-model monad maps a set to the set of all finite sequences of its elements, 
which is Haskell’s nondeterminism monad [24]. 

A user is usually presented with a way of browsing through those solutions, 
for example extracting all the solutions into a list. Since our calculus has no 
polymorphic lists (although it can easily be extended with them), we take base 
types a and list a , function symbols nil : () —> list a , cons : (a, list a ) —> list a , 
head:(list a ) —> a, tail:(list a ) —> list a , and append:(list a ,list Q ) —> list a . Then, 
all the results of a computation of type Fa can be extracted into a returned 
value of type Tlist c , using the handler 

(fail() 1—► return nil() , 

pick(zi, Z2) > letxi bezi in leta;2 bez2 in return append(a;i, x 2 )} . 

We can similarly devise a handler that returns the first solution, or one that 
prints out a solution and asks the user whether to continue the search or not. 
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6.5 Handlers with parameter passing 

Sometimes, we wish to handle different instances of the same operation dif¬ 
ferently, for example suppressing output after a certain number of characters. 
Although we handle operations in a fixed way, we can use handlers on a function 
type cr —> x t° simulate handlers on \ that pass around a parameter of type o. 
Instead of 

(x p :cr; z p : %).{op a .(z) \x:o.h op } ope z e!{ :((T;x) (a -*• x) handler . 

where all the occurrences of Zi(v) are applied to some v:a, the changed param¬ 
eter, we write 

(x p :cr; z p :x)-{op x (z)@x t-* /io P }o P ei; eff : (cr; x) handler , 

where h' op results from substituting z t (v)v for Zi(v)@v in h op . We also write 
try t with H ( u ; t)@v as x@y in t' 

instead of 

(try t with H(u; t) as a; in A y:a.t')v . 

We could similarly simulate mutually defined handlers by handlers on product 
types, but we know no interesting examples of their use. 

6.6 Timeout 

When the evaluation of a computation takes too long, we may want to abort it 
and provide a predefined result instead, a behaviour called timeout. 

We represent time by: a base signature with a base type int of integers, ap¬ 
propriate function symbols and a relation symbol >: (int, int), with the evident 
interpretation; an effect signature consisting of delay: 1, to represent the passage 
of some fixed amount of time, with the empty effect theory. Then timeout can 
be described by a handler which passes around a parameter T: int representing 
how long we are willing to wait before we abort the evaluation and return z p . 

(z p : W).{delay(z)@T H- delay(if T > Othen z@(T - 1) elsez p )} . 

Note that the handling term is wrapped in delay in order to preserve the time 
spent during the evaluation of the handled computation. 

6.7 Input redirection 

With parameter passing, we can implement the redirection proc < infile, 
which feeds the contents of infile to the standard input of proc. We take 
the base signature, etc., of Section 6.2, extended by the base type list c h ar , etc., 
of Section 6.4. Then a handler H ln : X@list c h ar handler to pass a string to a 
process is given by: 

{in(2:)@£ i-> if^= nil() then in(a.2:(a)@nil()) else 2(head(f'))@tail(^)} . 

Unfortunately we do not see how to implement the pipe ti|t2: the difficulty is 
very much like that with the CCS parallel combinator. 
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6.8 Rollback 


When a computation raises an exception while modifying the memory, for ex¬ 
ample, when a connection drops half-way through a database transaction, we 
want to revert all the modifications made. This behaviour is termed rollback. 

We take the base and the effect signatures for exceptions as in Example 1 and 
state as in Example 3, and the effect theory for state, together with the equation 
update; d (raise e ) = raise e for each exception e we deem unrecoverable [10]. In this 
case, the standard exception handler, extended to state, is not correct. Instead, 
we use a handler //rollback : X@(exc —* X) handler, which passes around a 
function that reverts the modified locations. Such a handler is given by 

{updat e l4 (z)@f ~ 

lookup;(d / .update; d ( 2 i@(Ae:exc. let x be fe in update; d , (a;)))) , 
lookup;^)®/ i-> lookup; (d.z(d)@f) , 
raise e ()@/ fe} , 

and is used on t:Fcr by handletwith i/ ro iiback@to for some to '■ exc —> Fa. 

We can also give a variant of rollback that passes around a list of changes to 
the memory, committed only after the computation has returned a value. 

7 Logic 

Since the notions needed to interpret the handling construct are present in all the 
interpretations of algebraic effects, it is relatively easy to adapt the logic for alge¬ 
braic effects of [11] to account for handlers. (In fact, handlers are already present 
in the logic in a way, as the free algebra principle allows an ad-hoc construction 
of models and guarantees the existence of the required unique homomorphism.) 

To incorporate handlers, we extend the language of the logic with handler 
types and terms, and state that the handling construct acts as a homomorphism 
by: 


r \~ try return u with H(u; t) as a: in t = t[u/x] , 
r b try op v (xi.ti)i with H(u; t) asxinf' = h op '[v/x] , 

where h' op is the computation term, obtained by taking the handling term h op 
and substituting try t^Vj/aq] with H(u: t ) as x in t for The principle of com¬ 

putation induction yields uniqueness. 

This principle was used in [11] to derive associativity and other properties of 
let binding and we can obtain analogous equations for the exception-handling 
construct, instead of taking them as axioms [13,16]. However, a general associa¬ 
tivity of the handling construct would have the form 

try (try ti with Hi asaq in t 2 ) with H 2 asx 2 inf 

= try t\ with H asaq in(try t 2 with H 2 asx 2 in t) , 
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but may not be expressible, as the model needed for H, the image of the model 
induced by Hi under the homomorphism induced by t 2 , may not be definable. 

Still, the associativity of exception handlers is not only expressible, but also 
derivable by induction, because, then, H\ = H exc (fi) and H 2 = fd exc ( fi ) for 
some fi: exc —> Fa^ and f 2 : exc —> r, and we can set 

H = de f H exc (Ae iexc. try fie with H 2 as #2 in t) . 


8 Recursion 

We sketch how to adapt the above ideas to deal with recursion. We work with 
w-cpos and continuous functions. Base signatures are as before; for their inter¬ 
pretations we use u'-cpos and continuous functions, still, however, interpreting 
arity types by countable sets, equipped with the trivial order (with some ad¬ 
ditional effort this can be generalised to countable w-cpos, in the categorical 
sense). Effect syntax is as before, except that we allow conditional inequations 
T; A h Ti < T 2 (ip) and assume there is always a constant fl and the inequation 
fl < w. We again obtain a category of models, now using tu-cpos (necessarily 
with a least element) and continuous functions; free models exist as before. 

Handler and computation syntax are also as before except that we add recur¬ 
sion terms fix:x-h and /ix: r.t (and so also computation variables) with the usual 
least fixed-point interpretation. Correct handlers cannot redefine fl because of 
the inequation fl < w. The adaptation of the logic of effects to allow recursion 
in [11] further adapts to handlers, analogously to the above; in this regard one 
notes that equations are admissible and therefore one may still use computation 
induction to prove associativity and so on. 

9 Conclusions 

Some immediate questions stem from the current work. The most important is 
how to simultaneously handle two computations to describe parallel operators, 
e.g., that of CCS or the UNIX pipe combinator: that would bring parallelism 
within the ambit of the algebraic theory of effects. More routinely, perhaps, the 
work done on combinations of effects [10] should be extended to combinations 
of handlers; one would also like a general operational semantics [4] including 
Benton and Kennedy’s in [13]. 

The separation between the languages for handlers and computations is es¬ 
sential in the development of this paper. A possible alternative is to give a single 
language and a mechanism limiting well-typed handlers to correct ones. This 
might be done by means of a suitable type-theory. 

It is interesting to compare our approach to that taken in Haskell [24], where 
a monad is given by a type with unit and binding maps. The type-checker only 
checks the signature of the maps, but not the monadic laws they should satisfy. 
Still, the only way to use effects in Haskell is through the use of the built-in mon¬ 
ads, and their laws were checked by their designers. Building on this similarity, 
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one can imagine extending Haskell in two ways: one could enrich the built-in 
effects with operations and handlers, and one could can give programmers a way 
write their own handlers, which have no direct access to effects, but which could 
be used to program in an extension of the monadic style. 

Monads, or algebraic theories, are used to model particular computational 
effects, and it is even possible for one monad to model distinct effects. For exam¬ 
ple the complexity monad N x — may account for either space or time. A given 
handler may or may not be computationally feasible for a given effect and there 
is a question as to which are. We may expect uniform handlers to be feasible, as 
they cannot use the properties of a specific data-type and so, one may imagine, 
cannot be as contrived. 

Lastly, one advantage of Benton and Kennedy’s handling construct is the 
elegant programming style it introduces. We gave various examples of our more 
general construct above; some used parameter-passing, but none, unfortunately, 
used mutually defined handlers. We hope our new programming construct proves 
useful, and we look forward to feedback from the programming community. 
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